o8F 


In our installation, our budget is not always sufficient 
for our requirements. That could be true in most installations, 
but in smaller shops the percentage of the data processing budget 
required for software would always be higher than a larger installa- 
tion, since basically all the same software is required. Because 
of this, either we do not always acquire the software we should 
have, or we support ‘home-grown' or 'free' software which requires 
more maintenance. As an example, IBM over the last few years has 
added different program products to the full MVS IPO system. In 
themselves, some of these products are not that expensive and most 
large installations already have them. But in our case, each time 
we have to justify this new product. Currently, we use a segmented 
IPO, not the full IPO, because of this. As well, monies to send 
technical staff on courses and to make a regular commitment to 
conferences we should be attending is a problem. 


Each systems programmer in a small MVS shop usually is 
responsible for the support of many different systems or products. 
There is not a situation where one or two people or even a group 
can specialize in a specific area. In this way, there is very 
little backup for a person, if any. It is very difficult to free 
staff for new projects because they are too busy, and if a pro- 
grammer leaves, the shop usually is in difficulty for a given 
period of time. The software environment can also be just as com- 
plex as in larger MVS shops. These complex smaller shops may have 
more manpower than some other smaller shops, but here each individual 
is heavily relied on to support multiple systems as well. 


Tuning an MVS system for a small user is different than 
for a large user. You have similar tuning concerns, but in a small 
shop you do not normally have all the tuning aids and monitors. 
Also, you do not have the luxury to dedicate volumes for swapping 
and paging. Usually you are restricted by a limited amount of DASD 
to perform the proper reconfigurations that you would like to make. 


These are some of the concerns I have come across as 
a small MVS user. 


CONCLUSION 


In conclusion, we feel that MVS can run quite well on 

a 3031 CPU, but like any other CPU that MVS runs on, MVS‘ per- 
formance is very dependent on the amount of real memory the com- 
puter has and the amount of DASD available to properly lay out 
paging and swapping data sets, and application volumes. Without 
sufficient memory and with a limited amount of DASD, we found 
that we have to restrict the use of the computer resources, 
especially during the prime shift when you are trying to provide 
an acceptable on-line response for your terminal users. We have 
had to cut back on our batch users to provide this response. This 
implies execution of their jobs during off-shifts and a reduction 
in the number of jobs submitted. 
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JCL Error Study -2- SHARE 61 

At the session today | hope to accomplish four things: 1) present 
the effect of a JCL error improvement in MVS SP 1.3.3, 2) discuss a 
JES2 change which supports automatic spelling correction, 3) show you 
the results of the JCL error survey, and, finally, 4) discuss JES2 
requirements for which no other working session is available. The 
shortage of meeting rooms at this SHARE left us no choice but to 
include that last item with the first three. 


We are very lucky to have two IBM representatives from the Con- 
verter/Interpreter here today. Leslie Dumas (IBM), as many of you 
will remember, discussed the Scheduler JCL Facility 6 months ago in 
San Francisco. Sandy Canetti (IBM) is, | believe, a new attendee at 
SHARE. [Give them the floor briefly. ] 


JCL Error Improvements in MVS/SP 1.3.3 


As most of you know, | have been collecting JCL error messages for 


about two years, both at my own site and at a couple others. Across 


the sites, we observed that 9 error messages represent around 85% of 
the messages JCL coders see, and we developed a requirement for IBM 
improvements to those messages. 


One of the messages, "Symbol Not Defined in Procedure" (IEF657), 
was dramatically improved in MVS/SP 1.3.3. Before, the message did 
not report the symbol the converter found offensive and did not tell 
where it found the symbol. Now, it provides both these vital facts 
about the error. Because improved specificity makes correction easier, 
| expected that the improved error message would reduced occurrences 
of the message. I! expected a reduction because difficult messages 
cause users to resubmit their jobs without change, or with ineffective 
changes. Improved specificity, | reasoned, would increase the chances 
of a successful correction the first time. 


John Kinn (CL), of Lockheed California Company, has MVS/SP 1.3.3 
and my JCL error collection modification installed on his system. He 
was kind enough to provide me with data. Before, in March, 1982, 
9.8% of his messages were "Symbol Not Defined in Procedure.” During 
a week in June, 1983, that number dropped to 1.7%, representing a 
shift of 8.1%. This shift is enormous. Without MVS SP 1.3.3, "Symbol 
Not Defined in Procedure" represents 8.6% of the error messages at 
BCG, and 9.4% of the error messages at CSG (Canada Systems Group, 
data courtesy of Terry Burr (CSG)). Thus, the greatest difference 
among the three sites was 1.2%. Compared with these numbers, the 
8.1% shift at Lockheed remains enormous. 


| conclude that improving error messages makes JCL easier to use, 


and recommend that you install MVS/SP 1.3.3 simply for the benefits of 
the improved message. 
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Symbol Not Defined in Procedure (IEF657) 
Error Frequency Improvement 


Message | 


IEF601 | 
EF603 | 
IEF605 | 
IEF607 | 
IEF610 | 
IEF611 | 
IEF612 | 
IEF613 | 
[EF617 | 
IEF618 | 
IEF621 | 
IEF622 | 
IEF623 | 
IEF624 | 
EF625 | 
[EF626 | 
IEF627 | 
IEF628 | 
IEF629 | 
[EF630 | 
[EF632 | 
IEF641_ | 
IEF642 | 
IEF647 | 
IEF650 | 
IEF651_ | 
[EF652 | 
IEF657 | 
[EF658 | 
IEF663 | 
IEF668 | 


TOTAL | 


Before 


April, 1982 


31 
1 
945 
178 
:) 
78 
74 
8 

3 
83 
478 
94 
103 
144 
52 
1 
42 
9 
44 
243 
227 
21 
14 
3 

2 
16 
83 
326 
ss) 

2 
11 


3327 


| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 


| 


NO 
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100% 
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| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
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After 


| 
June, 1983 (Week) | 


2 
0 
129 
24 
0 
11 
6 
0 
0 
' 8 
09 
6 
7 
29 
4 
0 
13 
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JES2 Automatic Spelling Correction 


Howard Morgan published a 


"Communications of the ACM" in February, 1970. 


0% | 


| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
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| 
| 

Change | 

-0.4% | 

-0.0% | 

3.33 | 

0.5% | 

-0.2% | 

0.4% 

-0.8% | 

-0.23 | 

ie 

0.18 | 

118 | 

2.8% | 

-0.63 | 

-0.0% | 

co 

0.6% | 

0.6% | 

1.33 | 

0.4% | 

-0.2% | 

-0.1%3 | 

-0.1% | 

-0.2% | 

-1.53 | 

-8.1% | 

0.3% | 

-0.1% | 

-0.1%3 | 


spelling correction technique 
The technique cor- 


rects keywords with any one of four possible errors: 
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Single missing letter, 
Single added letter, 
Single incorrect letter, or 
Adjacent letters transposed. 
JES2 support of the /*JOBPARM and /*OUTPUT cards was changed 
so that when the keyword search routine failed, a spelling correction 
routine was invoked. The change logs success or failure at correcting 


the keyword and the proposed corrected keyword. However, the cor- 
rected keyword is not used to continue job processing, so. that the 


change is customer transparent. We chose this route because we were 


not certain that spelling correction was effective, and did not want to 
commit ourselves to it before we knew the effect of the change. 


Our results are mixed. As previous work with JECL cards had sug- 
gested, incorrect keywords do represent around a third of the errors. 
However, the vast majority of those incorrect keywords do not reflect 
typographic errors. Instead, they represent conceptual errors: the 
keyword is specified on the wrong control card rather than being miss- 
pelled. 


a aR aR a ag || 
| Automatic Spelling Correction | 


jas 

| Month | JECL |Keyword| Fixed | 
| | Errors | Errors | | 
| February, 1983 | 4 | 12 «| 2 | 
| | | | | 
| March, 1983 | 35 | 11 | 0 | 
| | | | 
| April, 1983 | 53 | 18 | 7 | 
| | | | | 
| May, 1983 | 34 | 10 | 4 
| | | | | 
| June, 1983 | 52 | 16 | 5:- 1 
| | | | | 
J++ ____+ 
| Total | 205 | 67 | 15 | 
| | | | | 
| Percents | 100% | 33% | 73 | 
| | | | | 


My conclusion is that a specific error message reporting the incor- 
rect keyword is appropriate, but that automatic spelling correction 
needs more study. 
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JCL Error Survey Results 


In hopes of improving the business case for IBM improvements to the 
JCL converter, we conducted a survey about the impact of JCL on an 
operating environment. Our intent is to quantify the cost of JCL to an 
installation. Fifty one installations responded. Generally, we asked 
what tools customers use to avoid JCL. 


a ae ee en 
| JCL Avoidance Techniques | 


| Method | Percent | Lines | Man | 
| | Using | Needed | Years | 
| TSO CLISTs | 71% | 3000 | 11/4 | 
| TSO Commands | 40% | 1800 | 3/4 | 
| SPF Panels | 48% | 1400 | 1/2 | 
| VM/CMS EXECs | 108 | 500 | 1/4 | 


oo 
| | | Class | O-J-T | 


| | | Hours | Hours | 
| Training | 55% | 16 | 3 | 
| Other Computers | 215 | | 
| JCL Generators | 13% | | 
| Other Solutions | 40% | | 
| Migration Problems | | 19% | | 
| Favor Requirement | 65% | | 


The survey tells us that TSO CLISTs, Training, SPF Panels, and 
TSO commands are popular ways to cope with JCL. Further, it tells us 
that installations coping with JCL can easily invest a couple man-years 
in the problem. (Il got man-years by dividing lines of code using the 
empirical DOD formula: 10 lines of debugged (repeat, debugged) code 
a day, 240 work days in a year.) Finally, it tells us that people want 
improvements to JCL. 
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